With the development of mobile communication services, OMA DM becomes more and more important in the whole mobile operation server system, with its application improving network environment and lowering maintenance cost.
In an OMA DM protocol, a terminal having no DM function may gain, through a bootstrap, a capability of performing a DM with a server. The common three bootstraps are as follows:
1: Factory bootstrap (also called Customized bootstrap): all the information for a DM interaction is pre-produced in a terminal device when the terminal device is out of factory, needing no transmission of high-sensitivity information such as public key over the air, this Factory bootstrap has high security but low flexibility and is not applicable to all Original Equipment Manufacturers (OEM).
2: OTA bootstrap (also called Server initiated bootstrap): a terminal device having no DM function receives a bootstrap message from a DM server through a Wireless Application Protocol (WAP) Push or an Object Exchange (OBEX), and performs a bootstrap operation according to the content contained in the bootstrap message to gain a capability of having a DM session with the DM server, although having a capability of enabling a DM server to perform bootstrap for a terminal device for multiple times anytime anywhere based on needs, this highly-flexible OTA bootstrap method must transmit a great amount of sensitive information over the air and therefore takes a risk of receiving malicious bootstrap messages, so this OTA bootstrap method is not very secure.
3: Smartcard bootstrap: a terminal device reads information from an inserted smartcard to perform a bootstrap operation to gain a DM interaction capability, this method has high security but has increased cost as an inserted smartcard is required.
It can be seen from the analysis above that OTA bootstrap is the most flexible and efficient bootstrap method that can be applied to a network environment involving a terminal device, a user, a network server and a DM server, and the specific processing flow of an OTA bootstrap can be understood with reference to FIG. 1 in which the following steps are shown:
Step 101: a user registers in a terminal device;
Step 102: a network server detects the terminal device in the same network;
Step 103: determine whether or not the terminal device is registered in the current network (that is, whether or not the terminal device is usable);
Step S104: the network server sends an OTA bootstrap request to a DM server;
Step 105: the DM server feeds back a PUSH OTA bootstrap message;
Step 106: the terminal device performs an OTA bootstrap operation;
Step 107: the terminal device connects with the DM server to start a DM session with the latter.
In the flow shown in FIG. 1, the DM server may be an authorized DM server or an unauthorized one, that is, the terminal device may connect with an unauthorized DM server to leak DM management information to the unauthorized DM server, which will causes a big potential security hazard.
Therefore, although being flexible and efficient, OAT bootstrap is not used widely due to its potential security hazard. Although OMA DM protocol requires a Message Authentication Code (MAC) authentication for an OTA bootstrap and formulates a plurality of security mechanisms, for example, NETWPIN, USERPIN and USERNETWPIN, for the authentication, but is still incapable of preventing sensitive information (e.g. public key) from being cracked or leaked, for instance, after receiving an authenticated malicious bootstrap message and performing a bootstrap operation, a terminal device will be unable to perform normal function, or perform a DM interaction with an unauthorized DM server resulting in an authorized DM server losing the control over the terminal device without realizing it, and as a consequence, the DM management information of the terminal device will be leaked or modified maliciously, which will lead to a huge loss to the user.